Product documentation
This section describes how Service Objects are created, structured and managed within HSO Service Management. It explains how Service Objects form the foundation for service activities, maintenance, contractual coverage and service history, and introduces the functionality available for managing both individual equipment and complex installations.
Introduction
Service Objects represent the equipment, installations, locations or other entities for which service activities are performed. They form the central reference point for managing the technical configuration, contractual relationships and service history of equipment throughout its operational lifecycle.
A Service Object can represent a standalone item, such as a machine or vehicle, or form part of a larger installation. Depending on the requirements of the organization, Service Objects can be identified individually, grouped into pools or organized into hierarchical structures containing sub-objects and components.
Service Object identification and classification
Each Service Object is assigned an Object Type, which determines its primary classification and influences how it is managed within HSO Service Management. Object Types define applicable structural rules and provide the basis for associating service activities, such as inspections, maintenance and repairs, with specific categories of equipment.
Service Objects can be associated with customers in different roles, including owner, user and contract holder. This distinction is particularly relevant when equipment is owned by one organization, operated by another and maintained under a Service Contract held by a third party.
Service Object structures
For complex installations, Service Objects can be organized into hierarchical Object Structures. These structures allow individual parts of an installation to be represented as sub-objects or components, depending on the level of service history and financial tracking required.
Sub-objects are used when individual parts require their own operational and financial service history. Components represent elements on which Service Operations can be performed without requiring a separate Service Object and associated project administration. This approach supports detailed technical registration while avoiding unnecessary administrative complexity.
Service Object creation and maintenance
Service Objects can be created manually or generated through other business processes, including sales deliveries, equipment lists, Service Contract proposals and the Graphical Object Builder. The appropriate method depends on whether the organization is registering individual equipment, creating a complex installation or generating Service Objects from existing commercial transactions.
During their lifecycle, Service Objects can undergo maintenance, inspections, repairs and component replacements. Their technical configuration can change over time, while the associated service history provides insight into previous activities and the current serviced condition.
Integration with service processes
Service Objects are connected to the operational and commercial processes within HSO Service Management. Service Contracts determine applicable coverage and service obligations, while Service Calls and Service Tasks register and manage the work performed on the equipment.
Through integration with the project framework in Microsoft Dynamics 365 for Finance and Operations, service-related costs and revenues can be associated with the relevant Service Object and service activities. This provides a consistent connection between technical information, operational execution and financial history.
Additional Service Object capabilities
HSO Service Management includes functionality for managing different types of Service Objects and technical configurations. Object Templates and the Graphical Object Builder simplify the creation of standardized structures, while Service Object Pools support the management of groups of similar equipment.
Meters and Counters can be used to register equipment usage and support maintenance activities based on operating hours, mileage or other measurable values. These capabilities are described in greater detail in the following topics.
Introduction
Object Types are a fundamental configuration element within HSO Service Management. They classify Service Objects into groups with similar characteristics and service requirements, providing a consistent basis for creating, structuring and maintaining Service Objects.
An Object Type does considerably more than identify a category of equipment. It influences how Service Objects are structured, which service activities can be performed, which maintenance schedules apply and how information is defaulted throughout the service process. A well-designed Object Type structure is therefore essential for efficient service execution, consistent data registration and meaningful reporting.
Defining the appropriate level of detail
One of the most important decisions when configuring Object Types is determining the appropriate level of detail. Object Types should be specific enough to support meaningful service procedures and forecasts, but not so detailed that every equipment variation requires its own configuration.
For example, an Object Type named Vehicle may be too generic when different vehicle categories require significantly different maintenance activities, components and service procedures. Conversely, defining a separate Object Type for every individual model variation can create unnecessary complexity and make configuration difficult to maintain.
The objective is to identify groups of Service Objects that share sufficiently similar technical structures, service activities and maintenance requirements. Individual characteristics that do not influence these processes can generally be maintained at Service Object level rather than requiring additional Object Types.
Object Type classification
Object Types can be organized using Object Categories and Manufacturers. Object Categories provide a way to group related Object Types, while Manufacturers identify the manufacturer associated with an Object Type.
These classifications help organizations maintain a consistent equipment catalogue and support the selection, analysis and reporting of Service Objects.
Object Types and technical structures
Object Types play an important role in defining the technical structure of Service Objects. They determine which Component Types are permitted and how sub-objects can be incorporated into an Object Structure.
For example, an Object Type representing an industrial machine may allow components such as a motor, control panel and cooling system. Where a part of the installation requires its own Service Object and service history, the configuration can also define the permitted child Object Types.
Object Templates and the Graphical Object Builder use these definitions to support the creation of consistent technical structures. This reduces manual configuration and helps ensure that similar installations are represented in the same way.
Object Types and service activities
Object Types are closely connected to Event Codes, which define reusable service activities. The combination of an Object Type and an Event Code determines which activities are available for a Service Task and can provide predefined estimates for labor, materials, revenue and Service Operations.
For example, an Event Code for a periodic inspection may be applicable to several Object Types, while the estimated duration, required materials and inspection activities differ according to the equipment being serviced.
By maintaining these relationships centrally, organizations can standardize service work, improve forecasting and reduce the amount of information that must be entered manually when creating Service Tasks.
Maintenance and other configuration
Object Types can also provide defaults and configuration relationships for maintenance schedules, warranty handling and other service-related functionality. Depending on the requirements of the equipment, the configuration may include meters, technical properties and diagnostic information.
These settings help ensure that Service Objects created from the same Object Type receive a consistent starting configuration. They also provide the foundation for maintenance planning and the application of appropriate service procedures.
Design considerations
Object Type configuration should be based on the organization's actual service processes rather than solely on its product catalogue. Before defining an Object Type, consider whether the proposed group of Service Objects shares common technical structures, service activities, maintenance requirements and reporting needs.
Avoid creating separate Object Types for characteristics that do not affect service behavior. At the same time, avoid combining equipment with substantially different service requirements into a single generic Object Type.
A consistent and carefully designed Object Type structure simplifies subsequent configuration of Components, Event Codes, Object Templates and maintenance schedules. Because these relationships are used throughout HSO Service Management, Object Type design should be treated as an important part of the initial implementation.
Introduction
HSO Service Management supports several methods for creating Service Objects, depending on how equipment is registered, sold, installed or brought under service. Service Objects can be created individually, generated from sales-related processes, established through Service Contract proposals or created as part of a complex technical structure.
Selecting the appropriate creation method helps ensure that Service Objects are registered consistently, associated with the correct customers and prepared for subsequent service activities. Regardless of the method used, the resulting Service Object becomes part of the same service management framework.
Manual creation
Manual creation is suitable for individual Service Objects that do not require a complex technical structure or originate from an automated business process. Typical examples include existing customer equipment, individually registered machines or installations that are brought under service after delivery.
When creating a Service Object manually, the Object Type should be selected first because it determines important defaults and available configuration. The relevant customer relationships, service address, identification details and applicable warranty information can then be maintained.
Before the Service Object is used in operational processes, its configuration and associated project information should be reviewed. This helps prevent incorrect service history, missing service activities or problems with financial integration.
Graphical Object Builder
The Graphical Object Builder (GOB) is designed for creating Service Objects with more complex technical structures. It provides a graphical environment in which users can assemble an Object Structure using Object Types, Component Types, sub-objects, existing objects and predefined templates.
The available structural relationships are determined by the configuration of Object Types and Component Types. This helps ensure that only permitted combinations are used when constructing an installation.
Once the structure has been assembled and verified, the Write structure function creates the corresponding Service Objects, Components and underlying project structure. The Graphical Object Builder is particularly useful when multiple related Service Objects must be registered as a single installation.
Creation through sales delivery and equipment lists
Service Objects can also originate from the sales process in Microsoft Dynamics 365 for Finance and Operations. When an inventory item has been configured as an Object Item, its delivery can be used to register the equipment against the customer.
Depending on the Service Management parameter settings, posting the sales order packing slip adds eligible items to the customer's Equipment List. Service Objects can then be created automatically or registered from the Equipment List at a later stage.
Delayed creation can be useful when the actual installation date, warranty start date or service commencement differs from the original delivery date. This allows the organization to distinguish between equipment that has been delivered and equipment that has formally entered its service administration.
Object Items
Object Items establish the relationship between inventory items and Service Object creation. They identify which products are eligible to become Service Objects and support the transfer of relevant information from the sales process into Service Management.
This approach is particularly useful for organizations that sell equipment and subsequently provide installation, maintenance, warranty or repair services. It reduces duplicate registration and supports continuity between the delivered product and its subsequent service lifecycle.
Creation through Service Contract proposals
Service Objects can also be created while preparing a Service Contract proposal. This is useful when a contract covers equipment that has not yet been registered or when a new technical structure must be established as part of the proposed service agreement.
The creation process can use the same structural concepts as the Graphical Object Builder, allowing Service Objects and their Components to be prepared in the context of the contract.
This ensures that the relevant Service Objects and their technical structure are available when defining contractual coverage, maintenance requirements and other service obligations.
Choosing the appropriate creation method
The preferred creation method depends primarily on the origin and complexity of the equipment. Manual creation is appropriate for individual Service Objects, while the Graphical Object Builder is better suited to complex installations and hierarchical structures.
Sales-related creation methods are useful when equipment is delivered through standard sales processes, particularly when the organization wants to maintain a direct relationship between sold products and their subsequent service history. Creation through Service Contract proposals is appropriate when Service Objects are introduced as part of establishing a new service agreement.
These methods are complementary rather than competing approaches. An organization may use several of them depending on its operational processes.
Validation before service execution
Regardless of how a Service Object is created, its information should be reviewed before it is used in Service Calls, Service Tasks or Service Contracts. Particular attention should be given to the Object Type, customer relationships, service address, technical structure, warranty information and associated project configuration.
Incorrect or incomplete information can affect the availability of Event Codes, the application of contractual coverage, maintenance planning and the accuracy of operational and financial history.
Establishing consistent creation and validation procedures helps maintain reliable Service Object data throughout the service lifecycle.
Introduction
An Object Structure defines the hierarchical relationship between Service Objects, sub-objects and Components within HSO Service Management. It represents how an installation or piece of equipment is assembled and identifies which parts are maintained as individual Service Objects and which are represented as Components.
Object Structures are particularly relevant for complex installations consisting of multiple serviceable parts. The hierarchy provides the technical context for Service Calls, Service Tasks, Service Operations, maintenance activities and service history.
Service Objects, sub-objects and Components
An Object Structure consists of a main Service Object and, where applicable, one or more levels of sub-objects and Components. The distinction between sub-objects and Components determines how individual parts are administered.
A sub-object is a Service Object within a larger hierarchy. It is used when a part requires its own identification, contractual information, project history, financial tracking or replacement lifecycle. A Component, by contrast, represents a position or part within the structure where Service Operations, inspections or measurements can be registered without requiring a separate Service Object.
For example, an installation may contain a replaceable unit that requires its own service and financial history. That unit can be represented as a sub-object, while its individual inspection points can be represented as Components.
Defining the hierarchy
The permitted structure is determined by the configuration of Object Types and Component Types. These define which Components can be included under an Object Type and which child Object Types can be connected to particular Components.
Component Types can also act as positions or sockets into which sub-objects are placed. This allows organizations to define consistent structures for similar equipment while maintaining the distinction between structural positions and individually tracked Service Objects.
The complete Object Structure is maintained within the context of a Service Contract, allowing the hierarchy to be used when defining contractual coverage and maintenance arrangements.
Graphical Object Builder
The Graphical Object Builder (GOB) is the primary tool for creating and maintaining Object Structures. It allows users to assemble a hierarchy using configured Object Types, Component Types, existing Service Objects and Object Templates.
The available combinations are controlled by the configured relationships between Object Types and Component Types. Once the structure has been assembled, the Write structure function creates the corresponding Service Objects, Components and underlying project structure.
The Graphical Object Builder can also be used when preparing Object Structures within Service Contract proposals.
Object Structures and service execution
The position of a Service Object or Component within an Object Structure is relevant when performing service activities. Service Operations can be associated with specific Components, allowing inspections, measurements and other activities to be registered against the appropriate part of the installation.
The hierarchy also provides context for maintenance, warranty handling and service history. Where individual parts are maintained as sub-objects, their separate operational and financial history can be retained.
Object Templates
When the same technical structure is used repeatedly, Object Templates can be used to define reusable configurations. These templates are based on Object Types, Component Types and their permitted relationships, allowing similar Object Structures to be created consistently.
Object Templates and multi-level structures are described in more detail in the dedicated topic Object Templates.
Introduction
Components and sub-objects are used to represent individual parts of an Object Structure within HSO Service Management. Although both form part of a technical hierarchy, they serve different purposes.
Sub-objects are individually registered Service Objects with their own operational and financial history. Components represent structural positions or parts of an installation on which Service Operations can be performed, without requiring separate financial or logistical tracking.
Components and Component Types
A Component is a structural element within a Service Object. Components can represent parts such as an engine, pump, control panel or sensor, or positions within an installation where other Service Objects can be placed.
Component Types define these structural elements and determine which Components are permitted within particular Object Types. They also control which child Object Types may be connected to a Component, allowing the system to enforce the configured hierarchy.
For example, a Component Type representing an engine position may be configured to accept specific Object Types representing compatible engines.
Sub-objects
A sub-object is a Service Object that forms part of a larger Object Structure. Unlike a Component, a sub-object maintains its own identity and can have its own project and service history.
Sub-objects are used when individual parts of an installation require separate tracking of service activities, costs, revenues or replacements. They can also have their own Components, allowing Object Structures to contain multiple hierarchical levels.
The relationship between a parent Service Object and its sub-objects is defined through the configured Object Types and Component Types.
Components and Service Operations
Components provide the structural reference for Service Operations. Activities such as inspections, measurements, checks and calibrations are registered against Components rather than directly against the Service Object.
Service Operations can be defined through task templates associated with an Object Type and Event Code. These operations are available for execution when the corresponding Component Type exists within the Service Object's structure.
This relationship allows the same service activity to be applied consistently to the appropriate parts of different Service Objects.
Components and meters
Components can also be used to register meter information. A Component Type can be configured as a Meter Type, allowing a meter to be associated with the corresponding Component.
Depending on the configuration, meters can be created automatically when the Component is included in a Service Object. Meter readings are maintained as historical records and can be used to support meter-driven maintenance.
Choosing between a Component and a sub-object
The distinction depends on the level of tracking required. A Component is appropriate when a part primarily serves as a location for Service Operations, measurements or the placement of another Service Object.
A sub-object is appropriate when the part requires its own identification, project administration, financial history or replacement lifecycle. This distinction is established when designing the Object Types, Component Types and permitted relationships within the Object Structure.
The Graphical Object Builder uses these definitions when creating and maintaining hierarchical Service Objects.
Introduction
Object Templates are used to create predefined Service Object configurations within HSO Service Management. They allow organizations to reuse existing definitions when creating Service Objects, rather than manually assembling the same configuration each time.
HSO Service Management supports both standard Object Templates, which define the Components associated with an Object Type, and Multi-level Object Templates, which define complete hierarchical Object Structures.
Standard Object Templates
A standard Object Template defines which Components should be created for a particular Object Type. The template contains the applicable Component Types, based on the relationships configured for the Object Type.
When the template is selected in the Graphical Object Builder, its predefined Components can be used to create the Service Object structure. This is useful when Service Objects of the same type require a common set of Components for inspections, measurements or other Service Operations.
Multi-level Object Templates
Multi-level Object Templates extend this concept by defining complete Object Structures containing multiple levels of Service Objects, sub-objects and Components.
These templates use Object Types, Component Types, Object Items and the configured parent-child relationships to define reusable hierarchies. They are particularly relevant when an organization repeatedly creates the same installation or equipment configuration.
A Multi-level Object Template can be used in the Graphical Object Builder, Service Contract proposals and Equipment List functionality. When applied through the Equipment List, posting a sales order packing slip can generate an entire Object Structure rather than a single Service Object.
Template approval and versioning
Multi-level Object Templates support a controlled lifecycle. A template must be completed and approved before it becomes available for use in Service Management. This prevents templates that are still being prepared or verified from being used to create operational Service Objects.
Templates also support versioning and revocation. This allows outdated template versions to be withdrawn from use when a configuration has been revised.
Using Object Templates
Object Templates are used when creating Service Objects and Object Structures through the supported creation processes. The Graphical Object Builder applies the configured Object Types, Component Types and permitted relationships when assembling the resulting hierarchy.
Standard Object Templates are intended for recurring Component configurations, while Multi-level Object Templates are intended for complete, reusable hierarchies. Both reduce the need to recreate the same technical structure manually.
Introduction
Service Object Pools are used to group similar Service Objects when the operational and financial interest is primarily in the group rather than in each individual item. This is particularly relevant for lower-value equipment sold together, where the items share the same service conditions.
HSO Service Management distinguishes between regular Service Object Pools, in which individual items remain identifiable, and Anonymous Pools, which allow quantities of non-individually identified items to be handled together.
Service Object Pools
A regular Service Object Pool groups items that share common characteristics and service conditions. The individual items remain identifiable, for example by serial number, chassis number or license plate.
The items within a pool are expected to have the same:
End user, customer and service address.
Item number.
Warranty period.
Terms and conditions within the applicable Service Contract.
Service Object Pools can also be used in Service Contract proposals, allowing groups of similar items to be included in contractual arrangements.
Anonymous Pools
An Anonymous Pool is intended for situations where individual identification is not required for the service process. It is particularly useful for bulk operations in a repair workshop, such as refurbishment or conversion of multiple items.
Instead of registering a separate Service Object for each item, the system associates a single Service Call with a special Service Object representing the Anonymous Pool for the selected item. The Service Call handles the quantity of items involved.
Because the individual items are not separately identified within the pool, the associated service history is maintained at an aggregated level rather than as an individual history for each item.
Financial registration and item tracking
When an Anonymous Pool is used, the costs and revenues associated with the quantity being serviced are collected at Service Call level, using the corresponding call sub-project.
If the items being handled are serialized or have other active tracking dimensions, item lines are created at Service Call level to support repair history tracking.
Difference between regular and Anonymous Pools
The main distinction is whether the individual items remain identifiable.
A regular Service Object Pool groups individually identifiable items that share the same service conditions. An Anonymous Pool represents a quantity of items without maintaining a separate Service Object history for each individual item.
Both concepts allow groups of items to be handled within HSO Service Management, but they serve different operational requirements.
Introduction
Meters and Counters are used within HSO Service Management to register and maintain usage information for Service Objects. They provide a historical record of measurements such as operating hours, mileage, production cycles or other values relevant to equipment usage.
This information can be used to monitor equipment usage and support maintenance activities based on actual or estimated usage rather than fixed calendar intervals.
Meters and Components
A Meter or Counter is a separate entity associated with a Component within an Object Structure. The Component identifies the position to which the meter belongs, while the meter maintains the recorded values and their history.
Component Types can be configured as Meter Types. Depending on the Object Type configuration, the corresponding meter can be created automatically when a Service Object containing that Component is created.
Meter readings
Meter readings record a measured value at a specific date and time. The readings are retained as historical records, allowing usage to be tracked over time.
Readings can have different statuses, including verified readings. The documentation also distinguishes between actual, corrected, validated and estimated readings in the context of meter-driven maintenance.
When a meter is replaced or malfunctions, its counter can be reset. The system supports maintaining the historical readings associated with the meter.
Meter-driven maintenance
Meter readings can be used to determine when maintenance activities are required. This is particularly relevant for equipment where maintenance depends on usage, such as operating hours, kilometres or production cycles.
Meter-driven maintenance uses actual or calculated readings to determine when the next maintenance visit should take place. Depending on the recorded usage, a planned visit may be brought forward, remain at its original date or be moved to a later date.
For this functionality, the relevant Service Object must have the appropriate meter configuration and available readings. The maintenance calculation also depends on the applicable Service Schedule and its configuration.
Meter history and timeline
Registered meter readings are maintained over time, providing a chronological record of equipment usage. This history can be consulted to review recorded values, identify changes and understand the usage information available for maintenance calculations.
The Meter Timeline functionality provides a view of meter-related information over time.
Relationship with maintenance planning
Meters provide the usage information required for meter-driven maintenance, while the actual maintenance rules are defined through Service Schedules and the relevant Service Contract configuration.
The setup and execution of meter-driven maintenance are described in more detail in the Preventive and Planned Maintenance chapter.
Introduction
HSO Service Management maintains operational and financial information associated with Service Objects throughout their service lifecycle. This history provides insight into the service activities performed on equipment, its technical configuration and the costs and revenues associated with servicing it.
Service Object history is connected to Service Calls, Service Tasks, Service Operations and the underlying project administration in Microsoft Dynamics 365 for Finance and Operations.
Operational service history
Service Calls and Service Tasks provide the operational history of work performed on a Service Object. A Service Call records the service request and its handling, while the associated Service Tasks contain information about the work planned and executed.
Service Operations provide additional detail about activities performed on specific Components, such as inspections, checks and measurements. Together, these records allow previous service activities to be reviewed in the context of the relevant Service Object.
Technical configuration and replacement history
A Service Object can contain information about its original configuration (as built) and its current configuration following service activities (as serviced).
Within an Object Structure, sub-objects can be individually identified and tracked. When a sub-object is replaced, its individual identity and service history remain relevant, while the Component identifies the position within the structure where the replacement takes place.
This distinction allows the technical structure to reflect changes made during the service lifecycle without treating every Component as a separate Service Object.
Financial history
Service Objects are linked to the project framework in Microsoft Dynamics 365 for Finance and Operations. Service-related transactions, including labor, materials, expenses and revenues, are registered through the relevant projects and Service Calls.
Where individual parts of an installation require separate financial tracking, they can be represented as sub-objects with their own project history. Components do not require this separate project administration.
The project integration therefore provides the financial history associated with service execution, alongside the operational information maintained in Service Management.
Meter and maintenance history
Where meters are used, registered readings provide a historical record of equipment usage. These readings can be used in meter-driven maintenance and remain available for reviewing previous usage values.
Planned and completed maintenance activities are also connected to the relevant Service Objects through Service Calls and Service Tasks. This allows maintenance work to be considered alongside other service activities performed during the equipment's lifecycle.
History within Object Structures
For installations consisting of multiple Service Objects and Components, the Object Structure provides the context in which service history is interpreted.
The distinction between the parent Service Object, its sub-objects and its Components determines the level at which operational and financial information is maintained. Individual sub-objects retain their own history, while Service Operations are registered against the applicable Components.
This enables service history to be maintained at the appropriate level within a complex installation.